home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1994 March
/
Internet Info CD-ROM (Walnut Creek) (March 1994).iso
/
inet
/
ietf
/
nisi
/
nisi-minutes-91jul.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
9KB
|
294 lines
CURRENT_MEETING_REPORT_
Reported by Dana Sitzler/Merit
NISI Minutes
Agenda
o Review Activities
- Draft document available
- NSF nic solicitation
o Review Draft
- Security issues
- Information obligations
- Other issues
o Implementing Doc Suggestions
- Standard address (nic@domain)
- Info validity suggestions
- Nic-forum
- Nic profiles
- Discussion list
o What's Next
- Publish and disband
- Continue?
* X.500
* Archives
* User interface recommendations
Discussion:
1. Review Activities
A document from this Working Group has been submitted as an Internet
Draft. The draft document was used by NSF as one of the `inputs' in
preparing the NSFNET NIC solicitation.
2. Review Draft
The Working Group reviewed the draft document. We focused on the areas
of where internet community members expressed concern either via email
(as a result of the draft being available as a i-d) or in person during
the Working Group. The following list outlines the group consensus
which will be incorporated into the document.
1
2.1 Security Issues
There were some concerns expressed by the security area about the proper
role for NICs in this area. The Working Group came up with a list of
functions which it felt a NIC should deal with. This list will be
shared with the Security Area Director and some agreement reached before
these changes will be made in the document.
To deal with security issues, a NIC:
o Should be aware of security-related information/Educate users about
security issues.
o Should be aware of security advisories.
o May serve as the first point of contact for an end-user and should
know how to refer/escalate, etc.
o Should provide `new' users with information about security such as
referring to the Site Security HB.
o Should establish procedures for dealing with security `emergencies'
through coordination with NOCs.
o Can provide pointers to `security' software such as PC virus
disinfectant sw.
o Should be aware of and refer users (if appropriate) to security
organizations such as CERT.
2.2 Personal/Organizational Information
The Working Group discussed the responsibilities and obligations of a
NIC in providing personal or organizational information to the general
public. We had a rather long and interesting discussion of this topic.
We talked about the need to differentiate between different types of
information, privacy issues, the expense involved with information
collection and verification, and the trade-offs of having the info vs.
having `correct' info.
In terms of dealing with personal or organizational information, we
decided to provide a mechanism to inform the information provider about
what info is needed, what it will be used for, and if it will be made
widely available. Here's what we came up with:
o When collecting personal/organizational information, NICs should
provide a form which includes a `disclosure statement'.
o The `disclosure statement' should include:
2
- What information is needed?
- What it will be used for?
- The consequences of supplying the information?
- How widely available (and which info; some pieces may be made
more widely available than other pieces?
* Procedure for updating/correcting/disputing.
* Frequency of update.
* How to return the form (receipt of form w/requested
information would be considered an acknowledgement that the
info supplier agrees to the terms stated in the `disclosure
statement'.
o NICs should have a defined mechanism in place to update information
collected @ some time frame.
o The date of last update/verification should be included with the
information made available to others in the network community.
o NICs should understand and respect `levels of security' for
information -- if info should not be widely available to the
public, steps should be taken to make sure that the info is not
accessible by anyone.
2.3 Other Issues:
o NICs have different audiences -- emphasize in document the idea of
working with other NICs (in terms of referring to another NIC if
appropriate) and strengthen the idea of a `primary' audience for a
NIC which may have been funded by a specific group for a specific
purpose
o Increase examples in section outlining current NIC services. For
example, examples of archives, a specific online service, etc.
o Some discussion of recommending in document a common address for
NIC ftp servers -- lots of discussion here; no real consensus --
folks with strong opinions about this may want to lobby to continue
this discussion until some agreement can be made.
o Need to add section numbers.
o Shorten history section - does not add to document.
3 Implementing Draft Suggestions
3.1 Standard Email Address
The group had no problem with this recommendation. It was stressed that
3
NIC people involved with this Working Group have to start the process of
implementing this -- and informing users about it.
3.2 Info Validity Check Info
Much of this discussion was covered in the previous section dealing with
personal/organizational information. The basic suggestion to have all
information include a contact (which may be the NIC) and some indication
of the last verification
3.3 nic-forum
The group discussed the two components of the nic forum; the nic
profiles and the discussion list. The nic profile information sheet was
discussed and it was recommended that this sheet be made more `user
friendly!'. At present the profile sheet reflects the naming
conventions necessary for X.500 but not the ones common to all of us
human creatures. The profile sheet will be changed.
There was quite a bit of discussion about the discussion list aspect of
the nic forum. Who is the audience? Is it an open list? Should it be
moderated? Etc. A consensus was not reached on these issues. This
meeting was the first time the actual implementation of this suggestion
was discussed. The group agreed to continue discussion on the NISI
mailing list.
4 What's Next?
The group discussed the possibilities for the next step for NISI. The
following ideas were generated:
o Explore privacy issues.
o Develop an international profile database
o Develop an appropriate use document which addresses issues like
privacy, how to use services, starting `unsolicited stuff', etc.
o Define mechanisms for the exchange of information between groups
such as nics and nocs.
o Access mechanisms; X.500, Z.39.50.
o Define requirements for user interface.
o Archive
o New user nethelp system - start nethelp pilot.
o Expand ideas presented in existing document including how nics and
nocs interact; maintaining referral information; defining core
4
information at nic.
The general consensus was that the last item on this list was probably
an appropriate next step.
5 ACTIONS
o Update document.
o Review RARE Working Group profile.
o Discuss and agree to nic profile info and form (Sept).
o Discuss with USWG Chair -- NISI next step (given list above).
Attendees
James Conklin conklin@bitnic.educom.edu
John Curran jcurran@bbn.com
Peter Deutsch peterd@cc.mcgillica
Jill Foster jill.foster@newcastle.ac.uk
Maria Gallagher maria@nsipo.arc.nasa.gov
Arlene Getchell getchell@nersc.gov
Joe Godsil jgodsil@ncsa.uiuc.edu
Jack Hahn hahn@sura.net
Martyne Hallgren martyne@theory.tn.cornell.edu
Ittai Hershman ittai@nis.ans.net
Ellen Hoffman esh@merit.edu
J. Paul Holbrook holbrook@cic.net
Darren Kinley kinley@crim.ca
Christopher Kolb kolb@psi.com
Dale Land land@lanl.gov
Ruth Lang rlang@nisc.sri.com
Brian Lev lev@dftnic.gsfc.nasa.gov
Peter Liebscher plieb@sura.net
Daniel Long long@nic.near.net
April Marine april@nisc.sri.com
Karen McKelvey karen@cerf.net
Clifford Neuman bcn@isi.edu
Marsha Perrott mlp@andrew.cmu.edu
Joyce K. Reynolds jkrey@isi.edu
Timothy Salo tjs@msc.edu
Tom Sandoski tom@concert.net
Dana Sitzler dds@merit.edu
Patricia Smith psmith@merit.edu
Ronald Tencati tencati@nssdca.gsfc.nasa.gov
Theodore Tso tytso@mit.edu
Rudiger Volk rv@informatik.uni-dortmund.de
Chris Weider clw@merit.edu
Wengyik Yeong yeongw@psi.com
5